Method and apparatus for tunnelling data in a network

ABSTRACT

A communications network including nodes which permit networks to be tunnelled across intermediate networks. The present invention has application, in particular, to SDH networks, SONET and OTN. The content of entities for transportation across an existing network are mapped into a series of subframes and are virtually concatenated across the network. Each subframes is assigned a sequence indicator, which allows the original entity to be assembled at a remote node.

This application is the U.S. national phase of international applicationPCT/GB02/00361 filed 28 Jan. 2002 which designated the U.S.

BACKGROUND

1. Technical Field

The present invention relates to a method and apparatus for tunnellingdata in a network. In particular, but not exclusively, the inventionrelates to an optical communications network such as synchronous digitalhierarchy (SDH) networks or synchronous optical network (SONET) or anoptical transport network.

2. Related Art

SDH and SONET are standards for telecommunications networks. SDH is anInternational Standard. It is used throughout Europe. It is also used inother countries for international connections. SONET has beenstandardised for use in the US and Japan. The present invention isapplicable to both SDH or SONET. Communication networks for transportingSDH or SONET traffic are well known. SDH and SONET have become thedominant formats for transport in both national and internationalnetworks. In Europe, for example, as demand for bandwidth has increased,SDH has kept pace, with a capability to support client bit rates thatspan five orders of magnitude, from 1.5 Mbit/s to about 40 Gbit/s. TheSDH and SONET networks are not described in greater detail here, as thepresent invention is compatible with existing SDH and SONET networks.However, where necessary for the present invention to be understood,further details are given below. Where transmission and formattingoccurs with reference to a particular standard, these standards arereferred to in the description. Prior to transmission of data over anSDH or SONET network, the data is formatted into a frame. The SDH orSONET frames last 125 microseconds. There are thus, 8000 frames persecond. The frame includes an overhead area, which includes managementdata and a payload area (also known as a virtual container capacity)which includes the data for transmission. As the SDH or SONET frames aretransmitted through the SDH or SONET network, respectively, all orcertain parts of the overhead area are accessed by various networkelements. At the network nodes the data contained in the overhead areais converted from the optical domain to the electrical domain. Thenetwork nodes process the electronic overhead data using standarddigital processing techniques. The payload data is transmittedunaffected by the network elements through the network to a networktermination equipment depending on the management information containedin the overhead area. Depending upon the type of processing point, eg.regenerator, multiplexer, demultiplexer, add-drop multiplexer, digitalcross connect, etc, some or all of the overhead area may be accessed.

A problem with the present SDH and SONET frame structures is thatbecause data contained in the overhead area may be accessed at networkelements, it is not possible to transparently transport SDH or SONETframes over an SDH or SONET network, i.e. it is not possible totransport complete SDH or SONET frames over their respective networksintact without data in the overhead area being accessed, and in manycircumstances removed or replaced.

BRIEF SUMMARY

We have found that by mapping SDH or SONET frames in a particular wayprior to transmission, they may be tunnelled across existing SDH orSONET networks without the management information being accessed. Oneadvantage is that a network operator is able to manage a remote SDH orSONET network via an intermediate SDH or SONET network that may notnecessarily fall under his management responsibility. Similarly, iteffectively allows operators to transport the management data over anSDH or SONET network (i.e. the management information necessary tooperate SDH or SONET) over its own network, without the transportedmanagement data being accessed or corrupted. Operators may wish to carrytheir own SDH or SONET management data over their SDH or SONET networks.Alternatively, third parties may transmit their management data over theoperator's network.

In addition to SDH networks and SONET, the telecommunications industryis currently creating new standards to develop the next generation oftransport network, known as the optical transport network (OTN) withinthe ITU-T. The optical transport network is intended to be amulti-service network that supports a wide variety of layers includingSDH STM-N (synchronous transfer modules, where N=0, 1, 4, 16, 64 and Nindicates the bit rate of the module), SONET, asynchronous transfer mode(ATM), internet protocol (IP), as well as other formats, i.e to providea universal transport medium for high bandwidth services. The opticaltransport network (OTN) is based on a digital frame format which differsfrom those previously proposed. Reference is made to the ITU standardsat the heart of the optical transport network. These are G.872 andG.709. The present invention does not require any changes to be made tothe proposed frame structure of the entities to be transported over theoptical transport network as set out in the standards. Thus, theentities are described below only insofar as the present inventionrequires. As with SDH and SONET, an optical transport network transfersdata in frame formats having a payload area and an overhead area. Clientsignals are mapped into the payload area of the frame structure. As withSDH and SONET, the digital frame format provides an overhead area formanaging each signal carried on an optical carrier. This overhead area,as with SDH and SONET is, depending on the type of network node,accessed at network nodes. The digital data frame to be carried on theoptical transport network is called an optical transport unit (OTU). Itsformat is set out in G.709. FIG. 8 shows one typical structure of anoptical transport unit and this is described in the detailed descriptionhereinbelow. In brief, the payload to be carried for the client, i.e.the client signal, which may for example be ATM, SDH, STM-N, IP etc, ismapped into an optical payload unit (OPU). The optical payload unitcomes in different data rate sizes. For example, an optical payloadunit1 is approximately 2.5 Gbit/s, an optical payload unit 2 isapproximately 10 Gbit/s and an optical payload unit 3 is approximately40 Gbit/s. The optical payload unit (OPUk, where k is equal to 1, 2, 3)frame structure has two main areas, the OPUk overhead area and the OPUkpayload area, into which the client is mapped. The OPUk is then mappedinto an optical data unit (ODUk, where k is equal to 1, 2, 3). The twomain areas of the ODUk frame are the ODUk overhead area and the OPUkarea. The ODUk overhead area includes the management information for theframe. The ODUk is then mapped into an optical transport unit (OTUk,where k is equal to 1, 2, 3). The main areas of the OTUk are the ODUk, aforward error correction area (FEC) and some reserved area for OTUkoverhead. The k values for an OPUk, ODUk and an OTUk do not have to bethe same (i.e. an OPU1 does not have to be mapped into an ODU1, and anODU1 does not have to be mapped into an OTU1.

Although, there are clear benefits to be had from a universal, opticaltransport mechanism, such as an optical transport network, the framestructures of optical transport network data entities proposed by thestandard ITU-T Recommendation G.872 (2000), in particular the ODUks andthe OTUks are not suitable for transportation over existing standardisedSDH networks or SONET networks.

Thus, if OTNs are to be developed, the telecommunications industry isfaced with the problem of having to deploy a new transport networkinfrastructure. A new optical network would require the development andpurchase of completely new network components, plus the introduction ofa new network management control system to monitor and operate it. Thiscould be done as an overlay network or a replacement network. Either ofthese would be very expensive.

We have found, however, that by mapping optical transport units (OTUks)or optical data units (ODUks) in a particular way, it becomes possibleto transport the mapped entities across an existing SDH or SONETnetwork. In other words the optical transport network data entities arecarried by SDH or SONET networks, ie. The optical transport network dataentities are “clients” of SDH or SONET. This allows the existing SDHinfrastructure to be exploited to provide new services based on OTNentities. It also avoids the need for large-scale deployment of a newtransport network infrastructure.

We have found that the applications and advantages of the presentinvention include: Transport of optical transport network optical dataunits over SDH. During the transition from SDH to an optical transportnetwork there will be many instances where it will be advantageous tointerconnect optical transport network nodes using existing SDH paths.

The long haul submarine links that have many years of active life leftare attractive candidates, as are large legacy networks.

Transport of optical transport network optical transport units over SDH.Transport of other transport frames that encapsulate other transportformats such as SDH, IP, ATM, Frame-relay, and indeed almost any formatthat can be turned into ones and noughts at a constant bit rate.

Transport of an SDH STM-N frame over the SDH network. A network operatoris enabled to transport Optical Transport Network data entities, i.eoptical data units and/or optical transport units over other networkoperators SDH infrastructure. A network operator is enabled to transportoptical Transport Network data entities (ODU and/or OTU) from othernetwork operators' over their own infrastructure after converting thedata entities into SDH data entities.

The invention provides an extension to the useful life of the SDH andSONET platforms.

In accordance with a first aspect of the invention, there is provided amethod of tunnelling a first frame which includes data in an overheadarea and in a payload area, from a first network to a second network viaan intermediate network, a first node being disposed between said firstnetwork and said intermediate network and a second node being disposedbetween said intermediate network and said second network, the methodincluding the steps of:

-   -   a. at said first node, mapping said data of the first frame into        the payload areas of a plurality of second frames, the second        frames further including an overhead area which includes        overhead data relating to the transport of the second frames        over the intermediate network, assigning an identifier to each        overhead area of each of said second frames, and outputting said        second frames onto said intermediate network;    -   b. transporting said second frames across said intermediate        network to said second node in accordance with said overhead        data; and    -   c. at said second node, receiving said plurality of second        frames, accessing each of said identifiers, reassembling said        first frame from the payload areas of said second frames using        the identifiers accessed from said second frames, the        reassembled first frame including data in an overhead area and        in a payload area, and outputting said reassembled first frame        onto said second network.

Those skilled in the art will recognise that this embodiment encompassestunnelling a frame across an existing SDH or SONET network. Thus, inaccordance with the present invention, existing SDH networks are enabledto support all of the services that can be supported by the opticaltransport network for networking of STM-N frames. This allows foroptical transport network based services to be supported with minimumnetwork build during early stages of optical transport networkdeployment.

In accordance with a second aspect of the present invention, there isprovided a signal processor for use in step a) of claim 1, for mapping afirst frame which includes data in an overhead area and in a payloadarea, into a plurality of second frames, the signal processor includingan input for receiving said first frame of data, an output foroutputting the second frames, and processing means for mapping said dataof the first frame into the payload areas of the plurality of secondframes, the second frames further including an overhead area whichincludes overhead data relating to the transport of the second framesover the intermediate network, said node further including assignmentmeans for assigning to each of said second frames an identifier.

In accordance with a third aspect of the present invention, there isprovided a signal processor for use in step c) of claim 1, forreassembling a first frame of data from a plurality of second frames ofdata, including an input for receiving a plurality of second frames, anoutput for outputting said first frame, accessing means for accessingidentifiers assigned to each of said second frames, and reassemblingmeans for reassembling said first frame using said identifiers accessedfrom said second frames.

In accordance with a fourth aspect of the present invention, there isprovided a tunnelling apparatus for tunnelling a first frame whichincludes data in an overhead area and in a payload area, from a firstnetwork to a second network via an intermediate network, said apparatusincluding a first node having an input for receiving the first framefrom the first network and an output for outputting a second frame ontoan intermediate network, and a second node having an input for receivingsaid second frame from said intermediate network and an output foroutputting a reassembled first frame onto a second network, wherein saidfirst node further includes a mapper for mapping said data of the firstframe into payload areas of a plurality of second frames, the secondframes further including an overhead area which includes overhead datarelating to the transport of the second frames over the intermediatenetwork, said first node further including an assignment means forassigning an identifier to the overhead area of each of said pluralityof second frames, and wherein said second node further includesaccessing means for accessing said identifiers and reassembling meansfor reassembling said first frame from said plurality of second framesusing said identifiers.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the invention may be more fully understood embodimentsthereof will now be described, by way of example only, reference beingmade to the accompanying drawings in which:

FIG. 1 shows a communications link for transmission of an optical entityincluding nodes according to the present invention;

FIG. 2 shows a more detailed illustration of part of the communicationslink shown in FIG. 1, including an optical transport network node and anode according to the present invention;

FIG. 3 shows a detailed illustration of the structure of an opticalsignal processor according to the present invention, which is includedin the node shown in FIG. 2;

FIG. 4 shows a flow diagram illustrating the function of the opticalsignal processor according to the present invention and;

FIG. 5 shows an example of a mapping of an ODU1 into 17 VC-4s;

FIG. 6 shows a node according to the present invention;

FIG. 7 shows a flow diagram illustrating the function of a nodeaccording to the present invention;

FIG. 8 shows the relationship between the optical payload unit (OPU),the optical data unit (ODU) and the optical transport unit (OTU);

FIG. 9 shows a communications link for transmission of an SDH entityincluding nodes according to a the present invention;

FIG. 10 shows methods of interworking between a legacy network and a newnetwork;

FIG. 11 shows evolution paths from a legacy network to a new network.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Referring to the drawings, the present invention is applicable to thetransmission of various data formats, also known as “entities”,including SDH entities, SONET entities and optical transport networkentities. Preferably, the second frames are SDH or SONET data frames.The first data frames are either preferably SDH or SONET data frames oroptical transport network data frames. Also, according to the presentinvention data is mapped from the overhead area and the payload area ofthe first frame into the payload area of the second data frame.

FIG. 8 is referred to as it shows useful background to optical transportnetwork entities useful for appreciation of the invention describedbelow. FIG. 8 shows the relationship between the optical payload unit90, the optical data unit 94 and the optical transport unit 96. Theoptical transport unit 96 is the entity carried on each wavelength inthe optical transport network by means of optical channels. The ITU-T iscurrently developing a suite of recommendations that describe theoptical transport network. A central recommendation is G.872, providingthe architectural framework for the optical transport network. Referenceis made to ITU-T Recommendation G.872 (2000), “Architecture of opticaltransport networks”. It is based on a network model that contains threelayers;

-   -   An optical channel, OCh, layer network that provides end-to-end        networking    -   An optical multiplex section, OMS, layer network that provides        functionality for transport of a multi-wavelength optical signal        formed from a multiplex of optical channels    -   An optical transmission section, OTS, layer network that        provides functionality for transmission of optical signals on        optical fibre. This layer network also transports an optical        supervisory channel on a separate wavelength for management and        supervision of optical network elements.

Each optical channel is an optical carrier that supports a digital,optical transport unit 96. Three bit rates are defined for an opticaltransport unit 96, corresponding to approximately 2.5, 10 and 40 Gbit/s.These rates are represented, by k, the order of an optical transportunit. An optical transport unit k, where k is equal to 1,2,3 is composedof the following entities:

-   -   An optical payload unit of order k, 90 is an octet based frame        structure comprising 4 rows and 3810 columns. This structure is        subdivided into an overhead area, equivalent to the first two        columns and a payload area of 3808 columns. The format of the        overhead area 98 is dependent on the type of client mapping.    -   An optical data unit of order k, 94. This is an octet based        frame structure with 4 rows and 3824 columns that encapsulates        an optical payload unit of order k, 90 and adds 14 additional        columns of ODU overhead area 91. This overhead area 91 includes        a frame alignment signal, general communications channels,        maintenance signals, path monitoring, tandem connection        monitoring, protection control channels and experimental bytes.

An optical transport unit of order k, 96. This is an octet based framestructure based upon the optical data unit frame structure with anadditional 256 columns to provide a forward error correction area 92,also known as an FEC. A standard forward error correction area 92 basedon G.975 is used at inter-domain interfaces, between operators orvendors. Reference is made to ITU-T Recommendation G.975 (2000),“Forward error correction for submarine systems” (to be published). Atother points in the network a different FEC scheme and/or number ofcolumns for FEC 92 may be used. This allows vendors flexibility toexploit changes in technology whilst allowing interworking at agreedpoints in the network.

These entities and their relationships are shown in FIG. 8. Furtherdetail is not necessary for understanding of the present invention.However, a more detailed description of the frame structure can be foundin G.709. Refer to ITU-T Recommendation G.709 (2000), “Network nodeinterface for the optical transport network (OTN)” To be published. Theupto date version in December 2000 of G.709 defines mappings forOPU-ODU-OTU only for cases where k has the same value for each entity.There is, however, interest in digital multiplexing according to thefollowing rules:

-   four ODU1s are mapped into an ODU2, which is mapped into an OTU2,-   four ODU2s are mapped into an ODU3, which is mapped into an OTU3,    and-   sixteen ODU1s are mapped into an ODU3, which is mapped into an OTU3.

This will produce a digital multiplexing hierarchy similar to that ofSDH. One argument often used in favour of such a hierarchy is that itallows maximum utilisation of optical bandwidth. This will result in theneed for both optical channel cross-connects that switch in the opticaldomain and digital cross-connects that switch ODU entities. Such anetwork would be a direct competitor to SDH.

FIG. 1 shows apparatus incorporating the present invention. A network isshown, over which an optical entity is transmitted. In the example shownin FIG. 1 an optical transport network entity is transmitted across acommunications link. However, as mentioned above, the entity fortransmission is not limited to an optical transport network entity, butmay alternatively be an SDH or SONET entity. The communications linkincludes a first optical transport network node N1 and a second opticaltransport network node N2. Separate nodes N1 and N2 are conventional andmay each form parts of an optical transport network. Further opticaltransport nodes may be disposed upstream of node N1 and downstream ofnode N2, respectively. Alternatively, node N1 may simply generateoptical transport units for transportation, and node N2 may be areceiver for optical transport units. In both cases, the output of nodeN1 is arranged to output optical transport units, and the input of nodeN2 is arranged to receive optical transport units. The present inventionallows the transmission of an optical transport unit of the order k(OTUk) over an optical transport unit path from optical transportnetwork node N1 to optical transport network node N2 without the contentof the optical transport unit of order k being changed. The node N1 islinked via an optical fibre 3 to a node SNA, which is suitable forprocessing SDH signals and which includes a signal processor. Node SNAis described in further detail with reference to FIGS. 2, 3 and 4. NodeSNA is linked via optical fibres to a plurality of conventional SDHnodes (SN1, SN2, . . . SNM) 10, 12, and via further optical fibres to anode according to a second aspect of the present invention, SNB. NodeSNB is described in further detail with reference to FIGS. 5 and 6. SNBis further linked via an optical fibre to node N2. Conventional SDHnodes SN1 to SNM represent a conventional SDH network. The transportroute over which the entity is transported comprises portions 5, whichare shown in FIG. 1 between SNA and each of conventional SDH nodes SN1to SNM and between each of conventional SDH nodes SN1 to SNM and nodeN2, at the end of each transport portion 5, the signal may beregenerated for further transmission. Of course, a network may includeother transport portions or sections, however, for the sake ofsimplicity these are not shown.

Optical entities transmitted over nodes SN1 to SNM are processed in amanner typical of SDH networks, i.e. at each of nodes SN1 to SNM certainareas containing management data, for example the A1, A2, JO and B1bytes of the entities' overhead areas are accessed, read and replacedwith new management data for determining the management of the entity inits further transportation, before the entity is output for furthertransportation on the network.

In the example shown in FIG. 1 the optical transport network node N1outputs an optical transport unit of order k 96 by adding a forwarderror correction data 92 to an optical data unit of order k 94 (whosegeneration is not shown) for transport across the optical transmissionunit path 100 to node SNA. At node SNA the forward error correction data92 is stripped from the optical transport unit of order k 96 to producethe optical data unit of order k 94. In addition, at node SNA a signalprocessor maps the resulting optical data unit of order k frame contentincluding both the overhead area and the payload area into virtualcontainer-4 paths. This is in contrast to conventional SDH or SONETnodes which terminate the incoming frames, taking only the containedpayload area for further transmission.

A virtual container is the basic payload carrying unit of SDH frames.For a full discussion of virtual containers, reference is made to“Broadband networking: ATM SDH and SONET”, Sexton & Reid publisherArtech House or ITU-T Recommendation G.707.

As described in further detail below the number “4” indicates the sizeof the virtual container. Virtual containers (also referred tohereinbelow as VCs) may be transported in the SDH frame as datapackages. The virtual container has its own frame structure. The firstcolumn is typically reserved for the path management data as theoverhead area, the remainder of the virtual container is reserved forpayload. There exist different sizes of virtual container. For example,a virtual container-4 (VC-4) has a digital bit rate of 150.336 Mbit/s,and a frame size of 9 rows and 261 columns. In the example shown in FIG.1, the optical data unit of order k 94 is mapped into the payload areaof a plurality of VC-4s. The signal processor further inserts in theoverhead area of each VC-4 the management data necessary to manage thetransportation of each of the relevant VC-4s over the network. Thesignal processor further inserts in the overhead area of each VC-4 aunique identifier H4 (see FIG. 9) which identifies the position of eachVC-4 within the plurality of VC-4s that are generated. The VC-4sincluding their own management data are packed into STM-N frames, thestandard format for SDH transport. Because each VC-4 includes its ownrespective management data, the VC-4 may then be transportedindependently of each other across the network. This further enableseach VC-4 to be switched in the network independently of other VC-4s.This aspect of the invention is discussed in greater detail below.

The invention is not limited to the mapping of optical data units oforder k in to VC-4s. For example, the optical data unit of order k mayalso be mapped into other size virtual containers. For example theoptical entity may be mapped into VC-3, VC-2, VC-12 and VC-11. Fortransportation of optical data units of order k across SONET networks,for example, the optical data unit may be mapped into a synchronouspayload envelope (equivalent to a VC-3), which is referred to as asynchronous tranport signal-level 1, or STS-1.

Depending on the size and format of the optical data unit of order k,the optical data unit of order k will be mapped into X, where X is aninteger, VC-4 containers. FIGS. 2, 3 and 4 show in further detail howthe optical data unit of order k is mapped into X VC-4s.

The management data and unique identifiers assigned to each VC-4 allowthe plurality of VC-4s to be virtually concatenated across any one ofnodes SN1 to SNM to SNB.

Concatenation will now be described. SDH provides a mechanism,concatenation, to allow for transport of specified payloads that do notmap efficiently into one of the lower order (VC-11, VC-12, VC-2 or VC-3)or higher order (VC-3 or VC-4) paths. VC-4 concatenation, for example,allows for the transport of payloads with a capacity greater than oneVC-4. For a full discussion of concatenation reference is made to ITU-TRecommendation G.707. There are two types of concatenation, contiguousand virtual. Both forms provide a concatenated bandwidth of X times thebandwidth of a Container-N at the path termination. The differencebetween the two is in the manner that bandwidth is transported.

In the contiguous form the bandwidth of X container-Ns is bound togetherto form a single payload area and a single overhead area that togetherare transported over the SDH network as a single bandwidth entity. Theconcatenated container consists of a single payload area that is X timesthat of a container-N and X columns of overhead. Since a contiguouscontainer is effectively a single large container only one column ofoverhead is used for transport of management information in a mannersimilar to a container-N. The other X-1 columns of overhead are filledwith fixed stuff.

In order to indicate that the container is contiguously concatenated SDHuses a concatenation indicator in the administrative unit pointer (e.g.AU-4) as described in ITU-T Recommendation G.707.

Contiguous concatenation is described using the following notation:VC-n-Xcwhere n is equal to the order of the virtual container, X is an integervalue describing the number of virtual containers that are coupledtogether and c indicates that the form of concatenation is contiguous.For VC-4 contiguous concatenation the allowable values of X are 4, 16,64 and 256. The minimum interface rate that can support a VC-n-Xc is asynchronous transport module (STM) of order X. Support of contiguousconcatenation requires concatenation functionality at each networkelement in the VC-n-Xc path.

The present invention uses virtual concatenation—a type of inversemultiplexing. In inverse multiplexing rather than combining separatedata channels on a common communications link (as is the case formultiplexing), a data channel is divided and transmitted over aplurality of separate communications links.

In the present invention, the virtual containers are virtuallyconcatenated, which is illustrated in FIG. 1. The optical data unit oforder k is signal processed by a signal processor disposed at node SNAso that the virtual containers generated are able to be transportedusing virtual concatenation. This is achieved by a signal processordisposed at SNA for distributing the payload of the client, that is theoptical data unit of order k 94, between X individual virtualcontainers. Each virtual container includes an overhead area wheremanagement data for each virtual container is inserted for access andreplacement during transportation through the network. This allows thevirtual containers to be virtually concatenated across the networkbefore being recombined at node SNB to form the original payload.Because each virtual container includes its overhead area its ownmanagement data, there is no requirement for each of the individual VC'sto follow the same route across the network. At the node SNB, where thevirtually concatenated virtual containers are terminated, when theVC-n-Xv is terminated, it is necessary to compensate for thedifferential delay that results from using different networkconnections. In the case of VC-4 virtual concatenation the maximum delaytolerated is limited to 125 μs. For the present invention, only the pathtermination equipment, which in FIG. 1 is disposed in node SNB includesfunctionality to process virtually concatenated data entities. It is notnecessary to adapt intermediate network nodes SN1 to SNM to include anyfunctionality that extends beyond conventional SDH or SONET nodes. Asmentioned above, nodes SN1 to SNM are conventional SDH nodes.

Virtual concatenation may be described using the following notation:VC-n-XvWhere n is equal to the order of the virtual container, X is an integervalue describing the number of virtual containers, and v indicates thatthe form of concatenation is virtual. For VC-4 virtual concatenation theallowable values of X are any integer value within the range 2 and 256.

Although, virtual concatenation of some data formats is known, itsapplication is limited. Prior to the present invention, virtualconcatenation could only be used for the following applications:

-   -   transport of asynchronous transfer mode (ATM) virtual path        client layer networks,    -   transport of high level data link control (HDLC) framed signals,        including internet protocol (IP),    -   contiguous to virtual concatenation conversion.

Whilst virtual concatenation for data formats has been restricted toonly a small number of client layers with simple mappings, the inventorshave found that it may also be applied to the transport of opticaltransport network (OTN) as well as other entities, including SDH.

Thus, using the notation defined above, in FIG. 1 the optical data unitof order k is mapped into X VC-4 containers, VC-4-1v to VC-4-Xv. Eachvirtual concatenated VC-4 is assigned within the VC-4 overhead area aunique identifier, in particular, a sequence indicator, which allowseach of the virtual container-4s, 1 to X to have their position withinthe sequence of virtual containers identified, so that when the virtualcontainers arrive at the termination equipment the virtual containerscan be reordered in their correct sequence.

At node SNB, the VC-4s are terminated. The sequence indicators in eachVC-4 are accessed to enable the original optical data unit of order k tobe assembled. An assembler disposed at the node SNB assembles theoriginal data entity from the virtual containers received at the nodeSNB. How the signal processor disposed in node SNA map and the assemblerdisposed in the node SNB reassemble the original data entities, in theexample shown, the optical data units of order k 94, is discussed belowin more detail with reference to FIGS. 3, 4, 5, 6 and 7. The node SNBoutputs an optical data unit of order k 94. The content of the opticaldata unit of order k 94 output from the node SNB is substantiallyunchanged from that mapped at the node SNA, once the forward errorcorrection data 92 of the optical transmission unit of order k 96 hadbeen stripped. Thus, a network operator is able to transmit an opticaldata unit of order k 94 including its overhead area from one opticaltranport network node N1 to a second, or remote optical transportnetwork node N2 via conventional SDH nodes SN1 to SNM, without any ofthe data in the overhead area of the optical data unit of order k 94being changed en route. The present invention achieves this result withthe provision of two interfaces: a signal processor disposed in the nodeSNA and an assembler disposed in the node SNB. Of course, the inventionis also applicable to other situations where a network operator may wishfor certain parts of an optical data unit of order k 94, or otherentity, to be transmitted unchanged, whilst it may be desired that otherparts of the optical data unit of order k 94 overhead area should beaccessed.

In the example shown, further to assembling the optical data unit 94 oforder k, from the received VC-4s, there is disposed means at node SNB tooptionally add forward error correction data 92 to the assembled opticaldata unit of order k to form an optical transport unit 96 of order k fortransportation across an optical transport unit path 100 of order k, atthe end of which at node N2 the optical transport unit of order k may beterminated.

In the example shown, the VC-4s are transmitted independently over thenodes SN1 10 to SNM 12. The mapping of each of the VC-4s into STM-Nformat is conventional and standardised. For full details reference ismade to “Broadband networking: ATM SDH and SONET” Sexton & Reidpublisher Artech House or G.707. If the VC-4s in FIG. 1 were to bemapped into an STM-N frame, there would be M (where M is less than N)STM-N outputs from node SNA, because an STM-N frame where N is greaterthan 1 (4, 16, 64) has payload capacity to carry more than one VC-4,

FIG. 2 shows in more detail the format of the data entities concerned aswell as the mapping stages that take place between the input to theoptical transport network node N1 and the output of node SNA at whichthe signal processor 22 for carrying out the mapping is located. At theinput to the optical transport network node N1, optical data unit frames94 of order k are received. The optical transport network node N1 addsforward error correction data 92 to the optical data unit frame 94 oforder k to form an optical transport unit frame 96 of order k. Theoptical transport unit frame 96 of order k is output from the opticaltransport network node N1 and transmitted to node SNA, where the opticaltransport unit of order k is terminated and mapped. For terminating andmapping the optical transport unit frame 96 of order k, the node SNAincludes an optical transport unit of order k termination point 20 and aVC-4 mapper 22. The node SNA further includes a conventional STM-Nmapper 24 for mapping the VC-4s into standard STM-N frames fortransportation over the standard SDH network. The optical transport unitframe 96 of order k received at the optical transport unit terminationpoint 20 is terminated, i.e. the forward error correction data 96 isstripped from the frame and the optical transport unit overheadprocessed resulting in an optical data unit frame 94 of order k. Theoptical data unit frame 94 of order k is then received and processed bythe VC-4 mapper 22. The VC-mapper 22 outputs 32 ₁ to 32 _(X) a pluralityX of VC-4s, each of which have their own overhead areas within which asequence indicator is assigned. The number of outputs will depend on thenumber, X, of VC-4s generated. Each overhead area of each VC-4 furtherincludes management data for managing the transmission of each VC-4across the network to node SNB. The VC-4s are received by a plurality ofinputs and processed by the STM-N mapper 23 which maps the VC-4s intostandardised STM-N frames 95 before they are output on a plurality ofoutputs 33 ₁ to 33 _(N) from node SNA. The number, N, of outputs fromthe STM-N mapper will depend on the number of STM frames into which theVC-4s are mapped. The VC-4s as encapsulated in the STM frames are thentransported across a conventional SDH network. It is noted that thesequence indicator included in the overhead area is not accessed atintermediate nodes by virtue of its position within the overhead.However, data contained in the overhead areas of the virtual containers,including the sequence indicators may be observed by components, such asnodes, in the network, as the virtual containers are transported throughthe network.

FIG. 3 shows one preferred structure of the VC-4 mapper 22 included inthe node SNA shown in FIGS. 1 and 2. The VC-4 mapper 22 is a signalprocessor. The optical data unit of order k frame 94 is received at theinput 30. The VC-4 mapper 22 is adapted for the data rate of theincoming entity. This data rate will vary depending on the type ofentity. The VC-4 mapper 22 shown in FIG. 3 is adapted to receive opticaldata units of order k. However, the VC-4 mapper 22 may be furtheradapted to receive data entities having differing data rates, includingamongst others SDH and SONET entities. The bit rate of the incomingoptical transport network entity and the payload area of the virtualcontainer to be filled are used to determine how many virtual containerswill be filled. This will vary depending on the entity and theparticular container chosen. For example, an optical data unit of theorder 1 (ODU1) will be mapped into 17 VC-4s. In the example shown, thevirtual container is a VC-4. The use of virtual concatenation generallyutilises a number of separate virtual containers such as VC-11, VC-12,VC-2 or VC-4. However, the present invention may be extended to utilisea number of separate concatenated container such as VC-3-3c or VC-4-4c,provided that the overhead area for each separate concatenated entityincludes the management data necessary to allow each separate entity tobe transported in the network, and provided that each separate entity isassigned a sequence indicator. For example, an optical data unit oforder 2 (ODU2) can be mapped into 68 VC-4 or alternatively 17 VC-4-4c.The use of concatenated containers may require the use of additionalmanagement data in the path overhead area. This may be achieved, forexample, by using unused bytes in the path overhead area.

In the example shown in FIG. 3, the entity to be mapped is an opticaldata unit of order 1 and the entity into which it is mapped are VC-4s.The payload area is referred to as the C-4. If the ratio between the bitrate of the incoming entity and the bit rate of the virtual container isan integer, which is unlikely, the content of the optical transportnetwork entity is mapped by asynchronous mapper 39 directly into thepayload areas of the virtual containers. In this way the payload C-4generator 35 generates the appropriate number of C-4 payload areas. If,as is usual, the ratio of the bit rate of the incoming entity and thepayload area is not an integer, a fixed payload stuffer 40 provides afixed amount of extra payload into each payload area of the containerbefore the content of the optical transport network entity is mappedinto the remaining payload area by the asynchronous mapper 39. A localclock is preferably disposed local to the node SNA. Alternatively, itmay be disposed within the mapper 22. The bit rate of the incomingoptical transport entity is compared by comparator 41 with the localclock 34. If there is a difference between the local clock 41 and thedetected bit rate justifier 37 compensates the payload area (C-4)positively or negatively accordingly. If there is no difference,justifier 37 makes a zero justification.

A plurality of virtual container overhead areas are generated by anoverhead area generator 36. An overhead area is assigned to eachgenerated payload by the overhead generator 36. The sequence indicatorassigner 38 assigns an identifier to each overhead for each generatedpayload, which is unique and indicates the position each VC-4 has withinthe series VC-4-1v to VC-4-Xv. The overhead is added to each payloadC-4. The plurality of generated virtual containers are output on aplurality of outputs 32 ₁ to 32 _(X). The number of outputs can vary anddepends on the number of virtual containers generated.

FIG. 4 shows a flow diagram describing the function of the VC-4 mapper22. The number of VC-4's required for virtual concatenation of anoptical transport network entity can be found by dividing the bit rateof the optical transport network entity by the bit rate of the payloadarea of the entity into which the optical transport network entity is tobe mapped, for example the bit rate of the payload area of a VC-4. Thebit rate of the payload area is found by multiplying the number of bitsin the payload area by the number of frames per second. So for a VC-4having 260 rows by 9 columns, transported over an SDH or SONET network,whose frame duration is 125 microseconds to give 8000 frames per second,the bit rate of the payload area is equal to 260×9×8000×8 to convert tobits.

For the example worked below, it is assumed that the client entities ofinterest are the optical data unit and the optical transport unit.However, SDH entities may also be mapped according to the sameprinciples. A client data stream is divided equally between each of theC-4's. As the client data stream does not generally fill exactly aninteger 45 number of C-4s, it is necessary to provide data (also knownas fixed stuff) to pad the C-4 payload areas 47 and a means of mappingthe client into the remainder of the payload area 49. The mapping iscarried out asynchronously with respect to the clock. The mapping doesnot have to take place asynchronously. It may also be synchronous orplesiosynchronous with respect to the clock, although this is notnecessary. For an asynchronous mapping, any frequency difference betweenthe client and local C-4 clock 53 is accommodated by means of ajustification scheme, for example, a positive/negative/zero (pnz)justification scheme 51. Any justification scheme may be used, however,provided that it is compatible with virtual concatenation. Otherjustification schemes may include for example, positive justification.The bit rate tolerance of an ODUk is ±20 ppm.

The pnz mapping 55,57 provides for one positive justificationopportunity (PJO) and one negative justification opportunity (NJO) 55,57in each payload area C-4 of each VC-4. Traditionally, for purelypositive justification schemes, the justification ratio, which is alsoknown as the stuff ratio, is defined as the long-run average fraction ofjustification opportunities for which a justification is done (i.e., fora very large number of frames, the ratio of the number of justificationsto the total number of justification opportunities). In the pnz scheme,positive and negative justifications must be distinguished. This can beachieved using different algebraic signs for positive and negativejustifications. With this convention, the justification ratio can varyat most (for sufficiently large frequency offsets) from −1 to +1 (incontrast to a purely positive justification scheme, where justificationratio can vary at most from 0 to 1). Let α represent the justificationratio, where (−1≦α≦1), and use the further convention that a positive αcorresponds to negative justification and negative α to positivejustification.

Define the following notation:

-   N is equal to the number of fixed stuff bytes in the C-4 payload    area-   R^(c) is equal to the nominal client rate (byte/s)-   T is equal to the C-4 period-   β is equal to the ratio of actual frequency difference between the    C-4 frequency and client frequency and the nominal value of this    difference (the nominal value is the frequency difference between    the C-4 and client frequencies when both are nominal).-   N_(f) is equal to the average number of client bytes mapped into a    C-4, for the particular frequency offsets (averaged over a large    number of containers)

Then N_(f) is given byN _(f) =R ^(c) βT  (1)

However, the average number of client bytes mapped into a C-4 is alsoequal to the total number of bytes in the payload area (which is 260columns×9 rows=2340 bytes), minus the number of fixed stuff bytes (N),plus the average number of bytes stuffed over a very large number ofcontainers. The latter is equal to the justification ratio α. Combiningthis with equation (1) producesR ^(c) βT=2340−N+α  (2)

In equation (2), a positive α corresponds to more client bytes mappedinto the C-4 on average. However, this would correspond to negativejustification. This sign convention is used so that α enters in equation(2) with a positive sign (for convenience).

With the above, the range of α for each client mapping may bedetermined. It will be seen in the example below that α is in the range[−1 to 1]. The optical transport network entities of interest in thepresent example are the optical data unit and the optical transportunit. As an example consider the asynchronous mapping of an optical dataunit of order 1 (ODU1) signal into the payload area of a VC-4, i.e. theC-4.

The nominal rate of the client is 2498775126 bit/s (312346891 bytes).But the nominal rate mapped into each C-4 is 1/17^(th) of this or18373347 bytes. ThenR ^(c) T=18373347*125 μs=2296.668375 or 2297 bytes  (3)

Inserting this into equation (2), and using the fact that N is equal to43 (2340-2297), and assuming that this will be reduced by 1 to allow forthe NJO, for this mapping producesα=2297(β−1)  (4)

Since the C-4 and client frequency tolerances are each ±20 ppm (assumingSONET clock tolerance, for SDH clock tolerance it would be ±4.6 ppm), βranges from 0.99996 to 1.00004. Using this in equation (4) gives as therange of α−0.09188≦α≦+0.09188.  (5)

This approach can also be applied to describe the mapping of an opticaltransport unit of order 1 (OTU1), an optical data unit of order 2(ODU2), and an optical transport unit of order 2 (OTU2) into a C-4. Thevalues for α are shown in table I.

TABLE I Mapping of optical transport network entities into SDH virtuallyconcatenated VC-4's. Fixed stuff OTN Nominal bit Number of bytes perFixed stuff ratio entity rate kbit/s C-4s C-4 (alpha) ODU1 2498775.12617 43 −0.09188 ≦ α ≦  0.09188 OTU1 2666057.143 18 25 −0.09256 ≦ α ≦ 0.09256 ODU2 10037273.924 68 33 −0.09224 ≦ α ≦  0.09224 OTU210709225.316 72 15 −0.093 ≦ α ≦ 0.093

The mapping of an optical transport unit of order k (OTUk) is includedas it is possible that in certain circumstances part of the fieldreserved for the forward error correction data (FEC) will be used forcarrying other types of data. However, it is more likely that such avirtual concatenation scheme would be based on transport of optical dataunit entities to minimise the overall bandwidth.

Because each VC-4 contains in its overhead area management data for itstransportation across a communications link, each VC-4 may betransported independently of other VC-4s. Thus, different VC-4s may takedifferent routes through the network. This will result in a variationexisting between the arrival times of the VC-4s at the termination nodeSNB. In other words, due to different propagation delays of the VC-4s adifferential delay will occur between the individual VC-4s. Thisdifferential delay has to be compensated and the individual VC-4s haveto be realigned for access to the payload areas (Container-4s). Therealignment process has to cover at upto a differential delay of 125microseconds. A two stage 512 millisecond multiframe is introduced tocover differential delays of 125 microseconds and above (upto 256milliseconds). The first stage used H4 bits 5-8 for the 4 bit multiframeindicator (MFI1). The multiframe indicator (MFI1) is incremented everybasic frame and counts from 0 to 15. For the 8 bit multiframe indicatorof the second stage (MF12), H4, bits 1-4 in frame 0 (MRI2 bits 1-4) and1 (MFI2 bits 5-8) of the first multiframe are used. MFI2 is incrementedonce every multiframe of the first stage and counts from 0 to 255. Theresulting overall multiframe is 4096 frames (+512 ms) long. A fullerdiscussion of the sequence indicator behaviour is given in ITU-T G.707.

The sequence indicator SQ identifies the sequence/order in which theindividual VC-4s of the VC-4-Xv are combined to form the contiguouscontainer. Each VC-4 is assigned a fixed unique sequence number in therange of 0 to (X-1). The 8-bit sequence number (which supports values ofX up to 256) is transported in bits 1 to 4 of the H4 bytes. Thus, inaddition, a sequence indicator, H4x, where x is in the range 0 to X-1 isassigned to the overhead of each virtual container, VC-4, in the presentexample.

FIG. 5 shows an example of an optical transport network entity mappingbased on the discussion given above. The figure shows how an opticaldata unit of order 1 (ODU1) having 4 rows and 3824 columns is mappedinto 17 VC-4s, each having 9 rows and 261 columns, where the firstcolumn is reserved for the VC-4 path overhead area. As mentioned above,the sequence indicator (SQ) is transported in bits 1-4 of the H4 byte,where the indicator is zero for VC-4-1v and X-1 for VC-4-Xv.

In FIG. 5 some of the fixed stuff bytes are reallocated to otherfunctions. One byte is taken for the negative justification opportunity(NJO). In this case a further three bytes, labelled JC, are reserved forjustification control. A majority vote between the three bytes is usedto invoke a justification decision in the demapping process. Thisprotects against an error in one of the three JC signals. One possibleformat of these bytes is shown in table II. The skilled person willappreciate that other formats are possible.

TABLE II Justification control byte structure. Bits 1-6 can be set to000000 or reserved for future applications. Bits 7-8 indicate the statusof the positive, PJO, and negative, NJO, justification opportunitybytes. JC [7, 8] NJO PJO 00 justification byte data byte 01 data bytedata byte 10 Not applicable 11 justification byte justification byte

Some of the other fixed stuff bytes can also be assigned to carryoverhead information such as signalling channels or information from theterminated optical supervisory channel (where it is used).

One possible disadvantage of the present invention is that it is has adegree of inefficiency, approximately 6¼%. However, this is outweighedby the benefits of being able to transparently transport optical dataunit of order k (ODUk) frames over an existing SDH network.

The invention cannot currently be applied to ODU3 transport, thisrequires more than the maximum number of 256 VC-4 allowed by presentstandards for virtual concatenation. However, if standards were changed,and for example bigger data formats such as an STM-1024 were developed,it is envisaged that the present invention would be applicable to largeroptical transport network entities, including an ODU3 and larger. Atpresent, however, transport of ODU3/OTU3 represents a significantchallenge due to limitations of much of the world's installed fibrebase. Transport over either trans-atlantic and trans-pacific submarinecables is unlikely for the foreseeable future. Inverse multiplexing ofan ODU3 would require 5 rather than 4 ODU2's, due to the chosenmultiplexing structure, is very inefficient, and has not beenstandardised. To date, it is not clear when and how much ODU3/OTU3infrastructure will be deployed.

FIG. 6 shows a node SNB. The node SNB corresponds to the node having thesame reference numeral in FIG. 1 and is adapted to receive transmittedSTM-N frames and to assemble from received STM-N frames the originaloptical transport network entity or other type of entity, for example,SDH or SONET entity that was input to node SNA. The node SNB includes aplurality, N, of inputs 61 ₁ to 61 _(N), arranged to receive aplurality, N, of STM-N frames.

The STM-N frames received at the node SNB are input to conventionalSTM-N termination equipment 64. At the STM-N termination equipment 64,the STM-N frame is separated out in a conventional manner into theconstituent VC-4s before reaching the assembly module 62. The STM-Ntermination equipment 64 outputs a plurality, X, of VC-4s on aplurality, X, of outputs 65 ₁ to 65 _(X). The VC-4s output on outputs 65₁ to 65 _(X) are fed to an assembly module 62 which is a signalprocessor. The assembly module 62 assembles the original entity fromVC-4s as they arrive at the SNB. The assembly module 62 includes aninput for receiving VC-4s. The VC-4s are fed to a sequence indicatordetector 66, which detects whether the received VC-4s include a sequenceindicator. If the VC-4 received does not include a sequence indicator itis terminated at the node SNB in the conventional manner. If the VC-4does include a sequence indicator, each VC-4 is fed to a buffer 68 whichincludes a plurality of storage locations 68 ₁ to 68 _(X) for storingeach VC-4 until all virtually concatenated VC-4s which originated fromthe same optical data unit of order k (ODUk) are received. Once allVC-4s are stored at the buffer, the content of the buffer is fed to anassembler 70 which accesses the sequence indicators from the VC-4sreceived and using this sequence data assembles the original opticaldata unit of order k (ODUk) from the received VC-4s. At output 63, theassembly module 62 outputs the reassembled entity.

In the example given above, the assembly of an optical data unit oforder k from VC-4s is described. However, the present invention is notlimited in this respect, as previously discussed, other entitiesincluding but not limited to SDH or SONET entities may be assembledaccording to the present invention, from other data formats.

FIG. 7 shows a flow diagram illustrating the function of node SNB, asshown in FIG. 1, and as described in detail with reference to FIG. 6. Inparticular, FIG. 7 shows the processing steps carried out by theassembly module 62 by signal processing within the node SNB. Othercomponents of the SNB including termination equipment 64 areconventional. The node SNB detects the incoming data format that hasbeen transmitted across the communications link. In the example shownthis data format is STM-N frames or other entities that have been mappedinto VC-4s. The STM-N frames are input to the termination equipment 64which receives the STM-N frames, terminates them, and outputs aplurality of VC-4s. The assembly module 62 detects the incomingentities. In the example shown the entities input to the assembly module62 are VC-4s. The assembly module includes a sequence indicator detector66 which detects 74 whether or not the incoming entity includes asequence indicator, H4x, where x is an integer between 0 and X-1. If theentity does not include a sequence indicator the entity is terminated atthe node in the conventional manner 76. If the entity includes asequence indicator H4x, the payload area of the virtual container C-4and the sequence indicator are directed 80 to a buffer. When X virtualcontainers have been directed and their payload areas and sequenceindicators directed 82 to the buffer, the contents of the buffer isassembled 84 into order X=1, X=2 to X=X. In the example shown in FIG. 5an optical data unit of order 1 (ODU1) is mapped into 17 VC-4s, so X isequal to 17. However, X will vary depending on the entity mapped at SNA,and how it is mapped and the entity into which it is mapped. Once theentity has been assembled in the order predetermined by the sequenceindicators, the assembled entity is output from the assembly module 86.The output entity corresponds to the original entity that was mapped atSNA by the signal processor 22.

The embodiments described with reference to FIGS. 1-7 have particularapplication to optical transport networks (OTNs). As discussedpreviously, optical transport networks are “new” networks which arestill in the process of being standardised. “Old” networks are thosesuch as SDH and SONET networks which function according to acceptedstandards. Devices that allow a “new” network to be supported over an“old” network may be referred to as “modems”. The embodiments disclosedare optical transport network modems because they allow an opticaltransport network (a “new” network) to be supported over SDH (an “old”network). Optical transport network modems may be used in a number ofways. They permit rapid introduction of optical transport networkservices by exploiting the existing transport infrastructure.Effectively the modem extends the optical data unit (ODU) connectivityeven if the optical transport network is only provided at the edges ofthe network. Often when new technologies are introduced there is a lackof comprehensive operational support systems. An optical transportnetwork modem allows existing management infrastructure to be utilisedwith limited development of new features.

Optical transport network modems can be deployed to connect separateoptical transport network “islands”. The optical transport networknetwork is tunnelled through the intermediate SDH infrastructure thatconnects the “islands”. This may belong to the same operator as theoptical transport network “islands” or may belong to a differentoperator. Tunnelling allows optical transport network managementinformation to pass through the SDH network and offers the opportunityto remotely manage an optical “island”. The “islands” do not necessarilyhave to belong to the same operator. However, the owner of a first“island” linked to a second “island” owned by a second owner via anintermediate network owned by a third owner, would probably seek anarrangement with the second owner.

Optical transport network modems can also be used in conjunction withSDH based submarine cable systems or WDM line systems that have a largeamount of spare capacity and a long life-span but are unable directly tosupport optical transport units. Optical transport network modems may beemployed with an overlay model or with optical transport network nodesfirst or optical transport network line systems first. In contrast toevolution where payloads to be transported over a network are mappedover old layer networks onto the new layer network this form ofevolution (new on old) allows for a simple evolutionary path. There isno need for network wide coordination when changes are made and modemscan be retired as needed.

The applications for nodes supporting SDH over SDH or SONET over SONETor SDH over SONET or SONET over SDH are similar to those of opticaltransport network modems. That is the present invention allows an “old”network to be supported by an “old” network. The applications for SDH orSONET modems are similar to those of optical transport network modems.For example, it allows one network operator to transmit SDH managementdata to a remote network over a third party's intermediate network.

FIG. 9 shows a communications link for transmission of an SDH entityover an SDH network including nodes SNA and SNB according to embodimentsof the present invention. In FIG. 9 the SDH entity is transmittedtransparently, i.e. the overhead area of the SDH entity is not accessedby the intermediate nodes SN1 to SNM. The components shown in thecommunications link in FIG. 9 have analogous functions to those shown inFIG. 1. The link shown in FIG. 9 includes two conventional SDH nodes,node SNX and node SNY. The figure also shows STM-N paths over which theSTM-N entity is transported.

In FIG. 9, the node SNA includes a signal processor to map an incomingSDH entity, i.e. an STM-N frame, into virtual containers. The virtualcontainers are processed in the same manner as described with referenceto FIG. 1. An overhead area is generated for each virtual containerpayload area. Management data for each virtual container is assigned torespective overhead areas. Further, each virtual container is assignedin its overhead area a sequence identifier. Conventionally the entitythat is transported in an SDH network is the virtual container. Thevirtual containers will be formatted into STM-N frames prior totransportation across a communications link or network. Assigningmanagement data and a sequence identifier to each virtual containerallows each virtual container, as described with reference to FIG. 1, tobe transported independently of other virtual containers across acommunications link, that is the virtual containers may be virtuallyconcatenated across the communications link. Similarly to FIG. 1, thenode SNB includes an assembly module to assemble the original STM-Nframe from the virtual containers received which, as in FIG. 1, aretransported across intermediate nodes SN1 to SNM by virtualconcatenation.

The communications link shown in FIG. 9 allows SDH management dataincluded in the overhead areas of an STM-N frame to be tunnelled acrossan SDH network without that management data being altered atintermediate network nodes. In other words, it allows SDH networkmanagement data to be transported unchanged by an SDH network, and hasvarious applications. For example, network operators may wish to sellwavelength services on wavelength division multiplex (WDM) line systemsallowing semi-transparent transfer of SDH section overhead information.A WDM line system is connected to SDH equipment by means oftransponders. These are devices that take optical signals from anexisting SDH network and convert them into a form that the optical linesystem can use. For SDH, a laser that conforms to the ITU-TRecommendation G.957 specification has a broad spectral width and aloosely specified wavelength based on the 1300 or 1550 nm windows. Hencethere is no guarantee that two optical signals from an SDH equipment inthe 1550 nm window can be multiplexed together as nominally they are thesame wavelength. In contrast in a WDM network the wavelength andspectral width are both tightly defined.

From the perspective of the SDH equipment a WDM point to point system isinvisible—to each SDH optical section connection WDM system looks like afibre. Processing of the SDH frame within the transponder is thereforeseverely restricted. This is generally limited to reading the content ofbytes and not writing over them. This limited capability to monitorsignals at the ingress and egress to WDM line systems ensures that faultmanagement, though minimal, is possible. There are no standardsdescribing which bytes in the SDH section overhead are processed. Acommon approach is to process the frame alignment words A1, A2 which usea predefined pattern, and reading JO (trace) and B1 (for errors). Othersection overhead bytes are simply ignored.

Such a service is manually configured and put into operation.Flexibility can be introduced by means of an overlay allowingcross-connection of an entity that contained some of the sectionoverhead. The limitation of this approach is that the operator has lostmuch of its ability to manage the service. This can be overcome bymapping the STM-N into an optical data unit. Alternatively, asillustrated in FIG. 9, the STM-N frame can be encapsulated within SDHpaths using the virtual concatenation mechanism described fully withreference to FIGS. 1 to 4, to provide a fully transparent STM-N servicethat can be managed. The mapping relationships are given in table III.Hence, virtual concatenation can be used to provide SDH management dataover an SDH network. Prior to the present invention, this was notachievable.

TABLE III Mapping of STM-N entities into SDH virtually concatenatedVC-4's. Fixed stuff SDH Nominal bit rate Number of bytes per Fixed stuffratio entity kbit/s C-4's C-4 (alpha) STM-16 2488320 17 52 −0.09152 ≦ α≦  0.09152 STM-64 9952380 67 18 −0.09228 ≦ α ≦  0.09228

SDH systems are often used for transportation of synchronisation. Anysystem intending to transport STM-N signals must take this into account.It must be considered that optical transport networks will be used forsynchronisation transport and as such the following applies equally tooptical transport networks and SDH networks. The SDH frame is normallylocked to a network quality clock. At the receive end of the system thesame network clock can be directly extracted and re-used at the newlocation. Specifications for the quality of this transported clock, interms of jitter and wander are tighter than for normal datatransportation (Reference is made to G.811, G.812, G.813, and G.703. Seein particular, ITU-T Recommendation G.811(1997), timing requirements atthe outputs of primary reference clocks suitable for plesiochronousoperation of international digital links. ITU Recommendation G.812(1998), timing requirements at the outputs of slave clocks suitable forplesiochronous operation of international digital links. ITURecommendation G.813 (1996), timing characteristics of SDH equipmentslave clocks (SEC). ITU Recommendation G.703 (1998), physical/electricalcharacteristics of hierarchical digital interfaces.), which has causedproblems where SDH systems have been used to transport synchronisationsignals bound to plesiochronous digital hierarchy (PDH) signals withinthe SDH payload area. The main problem being that when an SDH equipmenthas to increment or decrement its pointer to the payload area the signalbeing presented at the output of the network will suffer a phaseperturbation. The magnitude and rate of this phase movement exceeds thelimits prescribed by synchronisation standards (though there is noeffect upon the data integrity of the payload area).

Several techniques have been proposed for reducing the effect ofpointers on the output phase of the data signal. There are howeverrealistically only three methods for reducing the effect to the pointwhere the payload area can be used for synchronisation transport.

-   1. Lower the desynchroniser bandwidth to the point that the    frequency components of any remaining jitter are below the relevant    requirements. This has an associated high cost in output buffer    requirements and introduces some delay to the final data signal. The    buffer cost has in the past precluded this. Also the quality of the    timing extraction circuits (or phase locked loop oscillators) has to    be improved which also increases cost.-   2. Deliberately introduce pointer movements at a high frequency. The    introduced signal can be modulated such that when the final    desynchroniser is encountered the resultant output jitter is very    low. This method is not favoured in practice and appears to remain    unproven in the network environment.-   3. Synchronise the bearer network to a high quality level so pointer    adjustments do not occur. This is used in most operator's networks.    In effect though, this only masks the problem, which can never be    reduced to zero. Also failures in the synchronisation network can    have an effect on the underlying data.

As outlined previously with reference to FIG. 6, the signal processordisposed in node SNB includes a buffer 68 to receive data over a periodof at least 125 μs. This allows the first technique to be re-visited asthe buffer is now available at effectively zero cost. The only remainingcost is in the higher timing extraction costs. However, we are now onlyintending to use this technique for carrying higher order payloads wherethis cost is much less significant than for lower order paths. It istherefore proposed that the techniques in (1) above will be able to meetrequirements for synchronisation transport of the underlying STM-N oroptical data unit (ODU) or optical transport unit (OTU).

Although, the examples given illustrating the present invention aredirected to SDH, the invention is equally applicable to SONET. SONETtransport may, for example, be based on VC-3 transport. The mapping,virtual concatenation and assembling mechanisms described according tothe present invention can also be used to carry SDH frames over a SONETpath based infrastructure and vice versa.

FIG. 10 shows methods of interworking between a legacy network and a newnetwork. It will be appreciated in the discussion below, that thepresent invention has an important and direct consequences on how a newnetwork, for example an optical transport network, can be introduced.

Unless a network operator constructs a new network with no legacyequipment for supporting old networks, the introduction of a newtransport technology immediately creates the dilemma of how to evolvefrom the legacy network to the new network. This depends upon anindividual network operators' choice of what types of equipment are tobe introduced, in what sequence and the types of mappings used. How anew network works with the old network is known as “interworking”. Inconsidering interworking between networks it is first necessary toconsider the client layer networks of both the old transport network andthe new network. SDH is a mature technology that supports a wide varietyof client layer mappings, as described G.707, see in particular, ITU-TRecommendation G.707 (2000), “Network node interface for the SynchronousDigital Hierarchy (SDH)” (not yet published). Below only mappings intothe higher order path layers are described, in particular the VC-4.These can be broadly divided into the following categories

-   -   pleisiosynchronous digital hierarchy (PDH) path layers,    -   Lower order SDH path layers    -   Client layer signals such as asynchronous transfer mode (ATM)        virtual path and high level data link control (HDLC) framed        signals such as internet protocol (IP).

For the purposes of the examples given below the last of thesecategories is chosen. The client layers of the optical transport networkas defined in G.709 are:

-   -   2 488 320 kbit/s, 9 953 280 kbit/s or 39 813 120 kbit/s signals        (with up to ±20 ppm bit rate tolerance) mapped into an optical        payload unit of order k(OPUk, where k is equal to 1,2,3). These        rates correspond to STM-16, STM-64 and STM-256. Mappings are        provided according to two different modes, asynchronous and bit        synchronous.    -   A constant bit rate ATM cell stream with a capacity that is        identical to the optical payload unit of order k (OPUk) payload        area.    -   Variable length Generic Frame Procedure (GFP) frames. These may        be used to transport internet protocol (IP), for example.    -   A non-specific client mapping into an optical payload unit of        order k (OPUk) is specified. Any (set of) client signal(s),        after encapsulation into a continuous bit stream with a bit rate        equivalent to that of the optical payload unit of order k (OPUk)        payload, can be mapped.

Interworking between new and existing layer networks can be achieved viaa client layer common to both the new and existing layer networks asshown in FIG. 10 a. This form of interworking requires the terminationof the respective SDH and optical transport network paths and theadaptation functions between the respective path layers and the clients.Such a combination of functions is referred to as transmultiplexing(TMUX). This requires processing at the client level when the serverlayers have different bit rates. Interworking in this manner iscompatible with the deployment of an optical transport network overlaynetwork where both optical transport network line systems andcross-connects (including add drop multiplexers (ADMs)) are deployedsimultaneously. This is the simplest form of interworking, requiring nodevelopment of new client-server relationships. In instances whereoptical transport network interfaces are subsequently deployed onnetwork elements that process client layer signals there are nointerworking requirements between such network elements and the opticaltransport network.

A second method of interworking is the transport of a client layer onthe old layer network (SDH), over the new layer network (the opticaltransport network) as shown in FIG. 10 b. As part of the migration frompleisiochronous digital hierarchy (PDH) to SDH, the PDH path layers werecarried on SDH paths. In contrast the optical transport networktransports complete SDH frames, STM-N's, rather than higher order paths.In effect the SDH section layer, which in SDH networks has staticconnectivity, has now become a path layer when transported over theoptical transport network.

Optical transport network technology can be introduced in one of thefollowing ways as part of a migration to a new transport network:

-   -   an overlay network as described above    -   deployment of optical transport network line systems first, with        interworking at the client level by means of transmultiplexing        (TMUXing). Optical transport network cross-connects or add-drop        multiplexers could subsequently be deployed to provide more        widespread optical data unit/optical channel (ODU/Och)        connectivity and the transmultiplexing function can be        discarded. Interworking is not required between optical        transport network cross-connects and line systems.    -   deployment of optical transport network cross-connects first,        with interworking at the client level by means of        transmultiplexing. This example is similar to previous example.        In this example, line systems can be introduced and the        transmultiplex function discarded.    -   deployment of optical transport network line systems first, with        transport of the old layer (the STM-N) over the new layer, the        optical data unit. Optical transport network nodes can then be        deployed between the nodes. The major limitation of this        approach is that the higher order paths and their clients are        effectively inaccessible. The STM-N can be retained, but if        interworking at the client layer is subsequently required then        the STM-N “paths” need to be removed. This is not a simple task        to implement and needs to be co-ordinated across the network.    -   deployment of optical transport network cross-connects first        with interworking at the STM-N level. The cross-connect provides        subnetwork connections for an STM-N, in other words, control of        connectivity. They can be used, for example, with existing        wavelength division multiplex (WDM) line systems. This        evolutionary route has the same problems as the other “old on        new” approach.

One further method of interworking can be envisaged. This involvestransport of a new path layer technology over an old path layertechnology as illustrated in FIG. 10 c. This is often required as partof a transition stage during the evolution from “old” to “new”. Byanalogy with the transition from analogue (“old”) to digital (“new”)networks, devices that allow a “new” network to be supported over an“old” network, as discussed above are known as modems. An example is themapping of SDH path layer signals into PDH path layer signals, formingSDH modem functionality, as described in G.832, see in particular, ITU-TRecommendation G.832 (1998), “Transport of SDH elements on PDHnetworks—frame and multiplexing structures. All of the possiblemigration paths are illustrated in FIG. 11.

At first it may seem that such a method of interworking is notapplicable between optical transport network based transport networksand SDH based transport networks. After all, an optical data unit oforder 1 (ODU1) frame can support an STM-16, but, as discussed earlier,the payload area of the latter clearly cannot support an optical dataunit of order 1 (ODU1). On the other hand the mapping of an optical dataunit of order 1 (ODU1) into a VC-4-64c has a very poor utilisation ofapproximately 28%. For these reasons the transport of optical transportnetwork entities over SDH had not previously been considered.

The present invention however has addressed this issue and provides asolution with application to both new and old networks.

The present invention provides solutions to interworking between SDH andthe optical transport network and outlined evolutionary paths from oneto the other. The virtual concatenation mechanism allows for thetransport of optical transport network entities over SDH paths. Opticaltransport network modems provide a mechanism that can be used to“thicken” an optical transport network overlay to provide morewidespread optical data unit connectivity using existing infrastructure.Optical transport network modems can be deployed at the edge of thenetwork to allow rapid take-up of optical transport network serviceswith minimum deployment of optical transport network functionality. Theyalso have the potential to extend the life of the SDH network. They arenot however restricted in their application to optical transportnetworks and can also be used to provide fully managed transparent STM-Ntransport.

1. A method of tunnelling a first frame which includes data in anoverhead area and in a payload area, from a first network to a secondnetwork via an intermediate network, a first node being disposed betweensaid first network and said intermediate network and a second node beingdisposed between said intermediate network and said second network, themethod including: a) at said first node, mapping said data of the firstframe into the payload areas of a plurality of second frames, the secondframes further including an overhead area which includes overhead datarelating to the transport of the second frames over the intermediatenetwork, assigning an identifier to each overhead area of each of saidsecond frames, and outputting said second frames onto said intermediatenetwork; b) transporting said second frames across said intermediatenetwork to said second node in accordance with said overhead data; andc) at said second node, receiving said plurality of second frames,accessing each of said identifiers, reassembling said first frame fromthe payload areas of said second frames using the identifiers accessedfrom said second frames, the reassembled first frame including the datain the overhead area and in the payload area, and outputting saidreassembled first frame onto said second network; wherein said firstframes are one of optical transport network data frames and SDH or SONETdata frames and said second frames are one of SDH and SONET frames.
 2. Amethod according to claim 1, wherein step a) includes mapping said datain said overhead and said payload areas of said first frame into thepayload areas of said plurality of second frames.
 3. A method formapping a first frame which includes data in an overhead area and in apayload area, from a first network towards a second network via anintermediate network, a first node being disposed between said firstnetwork and said intermediate network, said method comprising: mappingsaid first frame into a plurality of second frames, by receiving a firstframe of data and outputting second frames of data; mapping said data ofthe first frame into payload areas of the plurality of second frames,the second frames further including an overhead area which includesoverhead data relating to the transport of the second frames over theintermediate network; and assigning to each of said second frames anidentifier; wherein said second frames are SDH or SONET frames; andwherein said first frames are one of optical transport network dataframes and SDH or SONET data frames; reassembling a first frame of datafrom a plurality of second frames of data by receiving the plurality ofsecond frames and outputting a first frame, accessing identifiersassigned to each of said second frames, and reassembling said firstframe using said identifiers accessed from said second frames; andwherein said reassembling includes mapping data in the payload areas ofsaid second frames into appropriate overhead and payload areas of saidfirst frame in accordance with said identifiers.
 4. A tunnellingapparatus for tunnelling a first frame which includes data in anoverhead area and in a payload area, from a first network to a secondnetwork via an intermediate network, said apparatus including: a firstnode having an input for receiving the first frame from the firstnetwork and an output for outputting a second frame onto an intermediatenetwork, and a second node having an input for receiving said secondframe from said intermediate network and an output for outputting areassembled first frame onto a second network, wherein said first nodefurther includes a mapper for mapping said data of the first frame intopayload areas of a plurality of second frames, the second frames furtherincluding an overhead area which includes overhead data relating to thetransport of the second frames over the intermediate network, said firstnode further including an assignment means for assigning an identifierto the overhead area of each of said plurality of second frames, andwherein said second node further includes accessing means for accessingsaid identifiers and reassembling means for reassembling said firstframe from said plurality of second frames using said identifiers;wherein said second frames are SDH or SONET frames; and wherein saidfirst frames are one of optical transport network data frames and SDH orSONET data frames.
 5. An apparatus according to claim 4, wherein saidmapper maps said data in said overhead and said payload areas of saidfirst frame into the payload areas of said plurality of second frames.6. An apparatus according to claim 4, wherein said means forreassembling includes a mapper for mapping the data in said payloadareas of said second frames into appropriate overhead and payload areasof said first frame.
 7. A method of tunneling a first frame whichincludes data in an overhead area and in a payload area, from a firstnetwork to a second network via an intermediate network, the methodcomprising: mapping said data of the first frame into the payload areasof a plurality of second frames, the second frames further including anoverhead area which includes overhead data relating to the transport ofthe second frames over the intermediate network, assigning an identifierto each overhead area of each of said second frames, and outputting saidsecond frames onto said intermediate network; transporting said secondframes across said intermediate network in accordance with said overheaddata; and receiving said plurality of second frames, accessing each ofsaid identifiers, reassembling said first frame from the payload areasof said second frames using the identifiers accessed from said secondframes, the re-assembled first frame including the data in the overheadarea and in the payload area, and outputting said reassembled firstframe onto said second network; wherein said second frames are SDH orSONET frames; and wherein said first frames are one of optical transportnetwork data frames and SDH or SONET data frames.